grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist #3150

travier · 2024-01-31T14:42:20Z

grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist

With the new bootupd installation path in Anaconda, the
/etc/default/grub config file is not written anymore as we are only
using BLS configs with new enough bootloaders.

We thus don't need to generate (duplicated) legacy boot entries.

We still need to keep this logic in place in Atomic Desktops
(Silverblue, etc.) until we've actually landed bootupd there and forced
a bootloader update for everybody.

See: fedora-silverblue/issue-tracker#530
See: fedora-silverblue/issue-tracker#120
See: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd

grub2-15_ostree: Fix whitespace

With the new bootupd installation path in Anaconda, the `/etc/default/grub` config file is not written anymore as we are only using BLS configs with new enough bootloaders. We thus don't need to generate (duplicated) legacy boot entries. We still need to keep this logic in place in Atomic Desktops (Silverblue, etc.) until we've actually landed bootupd there and forced a bootloader update for everybody. See: fedora-silverblue/issue-tracker#530 See: fedora-silverblue/issue-tracker#120 See: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd

cgwalters

This is totally fine...however, the real fix here is anything using bootupd really must be setting sysroot.bootloader=none.

This is a messy bootupd-ostree integration issue, which is kind of sad given the two projects are designed to be used together 😄

One bikeshed here...at a practical level ostree could probably detect that bootupd+static grub configs is in use and automatically do the equivalent of bootloader=none.

cgwalters · 2024-01-31T15:21:23Z

One stance to take is that anything using bootupctl backend install --with-static-configs s should probably rm /usr/bin/grub2-mkconfig too in their builds. Then ostree can say "ok there's no grub2-mkconfig, I'm going to assume bootloader=none".

Anyways hmmm...it's actually kind of annoyingly hard to detect right now as bootupd doesn't really leave any explicit trace on the system that static configs are in use right now.

jlebon · 2024-01-31T16:35:05Z

This is nice because it works as that marker we were looking for to know that GRUB2 is new enough. (The issue IIRC with .grub2-blscfg-supported is that it was only added by the BLS migration script, and never taught to Anaconda.)

@cgwalters The static config stance makes sense (though in that case, couldn't --with-static-configs just directly set sysroot.bootloader=none?), though in the general case wouldn't this break dual boot systems?

cgwalters · 2024-01-31T16:42:09Z

@cgwalters The static config stance makes sense (though in that case, couldn't --with-static-configs just directly set sysroot.bootloader=none?),

At the moment, bootupd isn't really in a position to affect the ostree global configuration.

though in the general case wouldn't this break dual boot systems?

static configs inherently do that, yes.

jlebon · 2024-01-31T16:48:10Z

static configs inherently do that, yes.

I'm talking specifically about the general case. Basically, this statement:

the real fix here is anything using bootupd really must be setting sysroot.bootloader=none.

cgwalters · 2024-01-31T16:51:22Z

Yeah agree, we want to support bootupd with dynamic configs as well.

jlebon · 2024-01-31T17:27:28Z

This is nice because it works as that marker we were looking for to know that GRUB2 is new enough. (The issue IIRC with .grub2-blscfg-supported is that it was only added by the BLS migration script, and never taught to Anaconda.)

Though if it's a bug that Anaconda isn't writing /etc/default/grub in the bootupd path, then we should fix that, and while we're there make Anaconda add .grub2-blscfg-supported.

travier · 2024-01-31T17:52:55Z

Yeah agree, we want to support bootupd with dynamic configs as well.

Though if it's a bug that Anaconda isn't writing /etc/default/grub in the bootupd path, then we should fix that, and while we're there make Anaconda add .grub2-blscfg-supported.

If I understand correctly, this is OK, but we should also fix it in Anaconda to support dynamic GRUB configs? Do we really want to support non BLS configs?

travier · 2024-01-31T17:54:31Z

This is nice because it works as that marker we were looking for to know that GRUB2 is new enough. (The issue IIRC with .grub2-blscfg-supported is that it was only added by the BLS migration script, and never taught to Anaconda.)

Unfortunately it's only a marker that Anaconda detected bootupd in the image and is installing the system in this mode.

In general, systems installed with bootupd have a recent enough GRUB2 so that works, but there is no guarantee.

travier · 2024-01-31T17:56:01Z

CI failed but looks green in Jenkins UI so I don't know what happened.

travier · 2024-01-31T17:58:00Z

This is totally fine...however, the real fix here is anything using bootupd really must be setting sysroot.bootloader=none.

We will only be able to set that for everybody once we've installed bootupd everywhere and forced a bootloader update.

Or we could have Anaconda set this directly?

travier · 2024-01-31T18:03:03Z

Maybe I could do something like rhinstaller/anaconda#4240 and set sysroot.bootloader=none in the ostree repo config when we detect bootupd in the image?

travier · 2024-01-31T18:35:27Z

I've just found out that we have a script to switch systems to BLS and we never used it AFAIK: grub2-switch-to-blscfg (https://src.fedoraproject.org/rpms/grub2/c/7c2bab5e98d)

ericcurtin · 2024-01-31T18:43:35Z

We do this interesting thing with Android Bootloader support in that although the bootloader has no BLS concept from the OSTree userspace perspective it still uses the BLS files.

Currently our static configs don't directly support updates. (They really should) We also have a use case around simply introspecting the state that static configs were enabled (xref ostreedev/ostree#3150) where we want to have ostree not run grub2-mkconfig in this case. In preparation for both of these things, add tracking of our *own* version of the static configs into the metadata. In theory of course, static configs could include other components (ignition, greenboot, etc.) and we should track those too. For now this at least gets us basic metadata.

travier · 2024-02-01T11:45:16Z

11:27:17  FAIL: iso-live-login.bios (10m0s)
11:27:17      timed out after 10m0s
11:27:17  Running test: iso-live-login.uefi
11:37:24  FAIL: iso-live-login.uefi (10m0.006s)
11:37:24      timed out after 10m0s
11:37:24  Running test: iso-live-login.uefi-secure
11:47:15  FAIL: iso-live-login.uefi-secure (10m0.008s)
11:47:15      timed out after 10m0s

travier · 2024-02-01T11:58:03Z

I've verified that this fixes the installation for Silverblue.

travier · 2024-02-01T13:18:45Z

Looks like those tests failed on previous merge requests as well.

cgwalters · 2024-02-01T13:34:35Z

/override continuous-integration/jenkins/pr-merge

openshift-ci · 2024-02-01T13:34:44Z

@cgwalters: Overrode contexts on behalf of cgwalters: continuous-integration/jenkins/pr-merge

In response to this:

/override continuous-integration/jenkins/pr-merge

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

travier · 2024-02-01T14:05:30Z

Thanks

AdamWill · 2024-03-14T23:17:19Z

This is nice because it works as that marker we were looking for to know that GRUB2 is new enough. (The issue IIRC with .grub2-blscfg-supported is that it was only added by the BLS migration script, and never taught to Anaconda.)

Though if it's a bug that Anaconda isn't writing /etc/default/grub in the bootupd path, then we should fix that, and while we're there make Anaconda add .grub2-blscfg-supported.

Did we ever decide this?

I realized today openQA is running up against this. On aarch64 installs, at the end of install before we boot for the first time, we actually need to add a kernel parameter to see anything on the screen after the reboot (console=tty0). We currently (try to) do this by editing the file etc/default/grub in the installed system and then re-running grub2-mkconfig, but since IoT switched to bootupd, this doesn't work because that file isn't there.

I looked into it a bit, and while the PR commit message says "the /etc/default/grub config file is not written anymore as we are only using BLS configs with new enough bootloaders. We thus don't need to generate (duplicated) legacy boot entries", I'm not sure that follows? Looking at /etc/grub.d/10_linux, /etc/default/grub doesn't seem to be tied to only "legacy boot entries". update_bls_cmdline() in that file replaces the options line in all BLS entries it finds with a string that includes GRUB_CMDLINE_LINUX_DEFAULT, which (IIUC) is the contents of the GRUB_CMDLINE_LINUX line in /etc/default/grub.

anaconda writes various things in that file which we intend to be "Fedora defaults" - the timeout, the distributor, the rhgb quiet default args, things like that - so if we're not writing those into /etc/default/grub on the bootupd path, are they just not being applied at all? Is that what we want?

If not /etc/default/grub, is there some other way I can change the kernel params for a bootupd-based install before first boot, other than just straight up editing the grub config file directly? Or should I just do that?

cgwalters · 2024-03-15T01:46:55Z

Note that there's a difference between "bootupd" and "bootupd --with-static-configs". We're talking about the static configs path.

If not /etc/default/grub, is there some other way I can change the kernel params for a bootupd-based install before first boot

Anaconda today uses an ostree CLI that I was never very happy with to do this (which is the backend for the bootloader verb) but:

other than just straight up editing the grub config file directly?

The idea here is that the /boot/loader entries are a stable "API" that multiple tools can read and write. But we also ended up wrapping it with rpm-ostree kargs which is only designed to operate live.

cgwalters · 2024-03-15T01:51:19Z

What would definitely make sense is to not even install grub2-mkconfig or /etc/default/grub if bootupd static configs are in use; that would hopefully make things clearer.

AdamWill · 2024-03-15T05:38:02Z

Right now, on an install of an osbuild-built IoT image that uses bootupd, /etc/default/grub is not present, but grub2-mkconfig is.

ericcurtin · 2024-03-15T10:51:55Z

/boot/loader

I do think editing these entries is the most straightforward path today, but if they don't exists at the points described above, maybe it's worth reconsidering, 🤷

AdamWill · 2024-03-15T16:34:27Z

Thanks, that is what I've made openQA do. It does work.

ericcurtin · 2024-03-15T18:32:11Z

Thanks, that is what I've made openQA do. It does work.

Yay for standardized BLS configs!

travier added 2 commits January 31, 2024 15:38

grub2-15_ostree: Fix whitespace

5203d6d

travier mentioned this pull request Jan 31, 2024

Dual boot support for bootupd with static GRUB config installations fedora-silverblue/issue-tracker#530

Open

ericcurtin approved these changes Jan 31, 2024

View reviewed changes

cgwalters approved these changes Jan 31, 2024

View reviewed changes

cgwalters mentioned this pull request Jan 31, 2024

model: Add tracking of our own static config versions coreos/bootupd#609

Merged

cgwalters merged commit 7404131 into ostreedev:main Feb 1, 2024
24 checks passed

travier deleted the grub2-15_ostree-atomic-desktops branch February 1, 2024 13:54

cgwalters mentioned this pull request Feb 9, 2024

Ensure sysroot.bootloader=none CentOS/centos-bootc#97

Closed

henrywang mentioned this pull request Feb 27, 2024

Anaconda installation failed since centos-bootc-dev stream9.20240216.0 image CentOS/centos-bootc-dev#30

Closed

pcdubs mentioned this pull request Mar 15, 2024

Revert bootupd in IoT due to issues with the installer fedora-iot/iot-distro#34

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist #3150

grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist #3150

travier commented Jan 31, 2024

cgwalters left a comment

cgwalters commented Jan 31, 2024

jlebon commented Jan 31, 2024

cgwalters commented Jan 31, 2024

jlebon commented Jan 31, 2024

cgwalters commented Jan 31, 2024

jlebon commented Jan 31, 2024

travier commented Jan 31, 2024

travier commented Jan 31, 2024 •

edited

Loading

travier commented Jan 31, 2024

travier commented Jan 31, 2024

travier commented Jan 31, 2024

travier commented Jan 31, 2024

ericcurtin commented Jan 31, 2024

travier commented Feb 1, 2024

travier commented Feb 1, 2024

travier commented Feb 1, 2024

cgwalters commented Feb 1, 2024

openshift-ci bot commented Feb 1, 2024

travier commented Feb 1, 2024

AdamWill commented Mar 14, 2024 •

edited

Loading

cgwalters commented Mar 15, 2024

cgwalters commented Mar 15, 2024

AdamWill commented Mar 15, 2024

ericcurtin commented Mar 15, 2024

AdamWill commented Mar 15, 2024 •

edited

Loading

ericcurtin commented Mar 15, 2024

grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist #3150

grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist #3150

Conversation

travier commented Jan 31, 2024

cgwalters left a comment

Choose a reason for hiding this comment

cgwalters commented Jan 31, 2024

jlebon commented Jan 31, 2024

cgwalters commented Jan 31, 2024

jlebon commented Jan 31, 2024

cgwalters commented Jan 31, 2024

jlebon commented Jan 31, 2024

travier commented Jan 31, 2024

travier commented Jan 31, 2024 • edited Loading

travier commented Jan 31, 2024

travier commented Jan 31, 2024

travier commented Jan 31, 2024

travier commented Jan 31, 2024

ericcurtin commented Jan 31, 2024

travier commented Feb 1, 2024

travier commented Feb 1, 2024

travier commented Feb 1, 2024

cgwalters commented Feb 1, 2024

openshift-ci bot commented Feb 1, 2024

travier commented Feb 1, 2024

AdamWill commented Mar 14, 2024 • edited Loading

cgwalters commented Mar 15, 2024

cgwalters commented Mar 15, 2024

AdamWill commented Mar 15, 2024

ericcurtin commented Mar 15, 2024

AdamWill commented Mar 15, 2024 • edited Loading

ericcurtin commented Mar 15, 2024

travier commented Jan 31, 2024 •

edited

Loading

AdamWill commented Mar 14, 2024 •

edited

Loading

AdamWill commented Mar 15, 2024 •

edited

Loading